Organize versioned controllers into subdirectories (v1/, v2/) within each feature module folder. The feature module imports both controller classes. Shared DTOs live in a dto/ subdirectory outside the version folders. For small APIs, version-specific logic can live in service methods instead of separate service classes.
v1/ and v2/ subdirectories keep version-specific code isolated and independently testable.
Shared DTOs go in a common dto/ folder — versioning only applies to the request/response layer.
For large teams, separate service classes per version prevent one version's changes from breaking another.
For small APIs, a single service with version-branching logic is acceptable to avoid code duplication.
The module registers all controller versions — clients route to the right one via the versioning strategy.
We need to add a v2 of the Users API to a small NestJS project that currently only has v1. How would you lay out the controller files and modules?
If you placed the v2 UsersController in the same folder as the v1 controller, what issues could arise during routing or testing?
During a sprint, a teammate added a new endpoint to the v2 OrdersController but accidentally imported it into the v1 OrdersModule, causing a 404 at runtime. How would you locate and fix the problem?
We have a feature that must be released to v2 first, then rolled back to v1 if needed. Explain how you would structure the files and versioning configuration to support this workflow.
Our monorepo now contains ten versioned modules (v1‑v10) with many shared services. Discuss the trade‑offs between a flat version folder (src/v1, src/v2, …) versus a nested per‑feature structure (src/users/v1, src/users/v2). Consider build time, test isolation, and developer onboarding.
You need to share validation logic across all versions without duplicating code. How would you organize the file hierarchy and Nest modules to keep versioned controllers separate but still reuse common utilities?
The organization is moving from a custom versioning approach to NestJS's built‑in versioning across dozens of microservices. What architectural changes to the file structure would you recommend to minimize disruption and make future version increments painless?
Design a versioned controller strategy that can comfortably scale to 15+ API versions while allowing new teams to add their own versioned features without deep knowledge of existing layout. What conventions and folder patterns would you enforce?